WORLD INTELLECTUAL PROPERTY ORGANIZATION 
Internationa] Bureau 




PCX 

INTERNATIONAL APPUCATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification ^ : 




(11) International Publication Number: 


WO 97/24671 


G06F 11/30, 9/00 


Al 


(43) International Publication Date: 


10 July 1997 (10.07.97) 



(21) International Application Number: PCT/US96/20126 

(22) International FHing Date: 23 December 1996 (23.12.96) 



(30) Priority Data: 

08/578,203 



29 December 1 995 (29. 1 2.95) US 



(71) AppUcant: POWERTV, INC. [US/US]; Suite 100, 20833 

Stevens Creek Boulevard, Cupertino. C A 95014 (US). 

(72) Inventor: HOUHA. James. A.; Powertv. Inc.. Suite 100. 20833 

Stevens Creek Boulevard. Cupertino. CA 95014 (US). 

(74) Agents: POTENTIA. Joseph. M. ct al.; Banner & Witcoff. Ltd.. 
nth floor. 1001 G Street, N.W.. Washington. DC 20001- 
4597 (US). 



(81) Designated SUtes: AL, AM. AT. AU, AZ, BA. BB. BG. BR, 
BY. CA. CH. CN. CU. CZ. DE. DK, EE, ES. FI. GB, GE, 
HU. IL, IS. JP. KE. KG. KP, KR, KZ. LC, LK, LR. LS. 
LT, LU, LV. MD. MG. MK. MN. MW. MX. NO, NZ, PL, 
PT. RO. RU. SD. SE. SG. SI, SK, TJ. TM, TR. TT. UA, 
UG. UZ. VN, ARIPO patent (KE, LS. MW. SD, SZ. UG). 
Eurasian patent (AM. AZ. BY. KG. KZ, MD, RU. TJ. TM), 
European patent (AT, BE. CH. DE. DK. ES, FI. FR. GB, 
GR. IE, IT. LU. MC. NL, PT. SE). OAPI patent (BP. BJ. 
CF. CG. CI. CM, GA, GN. ML. MR. NE. SN. TD. TG). 



Published 

With international search report. 

Before the expiration of the time limit for amending the 
claims and to be republished in the event of the receipt of 
amendments. 




(54) Tide: 



EVENT FILTERING FEATURE FOR 
TERMINAL 



A COMPUTER OPERATING SYSTEM IN A HOME COMMUNICATIONS 





/'SOD 
















UASX1 




MASKS 


MASX3 




















ii i[ieri-A'i y nnigYi V 



oowntouERvi 

— f — 

TOsnmoN'A* PRESS yousEomoN 



MOUSE f1 I 

T 



(57) Abstract 

An improved operating system kernel for a h<mie conmiunication terminal (HCT) includes an event filtering feature (204) which 
allows threads (A, B) running in the HCT to register interest in events of a particular type, from a particular source, or other desirable 
criteria. Events occurring in the system (205, 206) are prequalified by the kemel before providing them to individual threads which have 
registered interest in only certain types of events. By executing a fitter in the kernel's context, a thread context switch can be avoided. 
Events occurring in the system can be matched with events of interest (200a, 200b. 200c) registered by various threads by an efficient 
comparison operation including a mask field and a code field. Additionally, various thread synchronization mechanisms such as alarms and 
semaphores can be implmented using a common event object which is integrated onto event queues. 
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EVENT FILTERING FEATURE 
FOR A COMPUTER OPERATING SYSTEM 
IN A HOME COMMUNICATIONS TERMINAL 

BACKGROUND OF THE INVENTION 

1. Technical Field 

This invention relates generally to real-time operating systems adapted for 
high performance applications, such as those executing in a home 
communications terminal (HCT) to provide cable television or other audiovisual 
capabilities. More particularly, the invention provides a feature which improves 
the performaix:e of operating, systems installed in devices having limited 
computing resources. 

2. Related Information 

Conventional operating systems for HCTs, such as those in cable 
television systems, have typically provided limited capabilities tailored to 
controlling hardware devices and allowing a user to step through limited menus 
and displays. As growth in the cable television industry has fostered new 
capabilities including interactive video games » video-on-demand, downloadable 
applications, higher performaiK:e graphics, multimedia applications and the like, 
there has evolved a need to provide operating systems for HCTs which can 
support these new capabilities. Additionally, newer generations of fiber-based 
networks have vastly increased the data bandwidths which can be transferred to 
and from individual homes, allowing entirely new uses to be developed for the 
HCTs. Changing federal and state regulations also portend new uses such as 
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teiephony to be available through existing cable netwoilcs. As a result, 
conventional HCTs and their operating systems are quickly becoming obsolete. 
In short, HCTs need to evolve to transform today's limited capability television 
sets into interactive multimedia entertainment and communication systems. 

One possible approach for increasing the capabilities of HCTs is to port 
existing operating systems, such as UNIX or the like, to PC-compatible 
microprocessors in the HCT. However, the huge memory reouirements needed 
to support such existing operating systems render such an approach prohibitively 
expensive. Because memory is a primary cost component of HCTs, competitive 
price pressures mean that the added functions must be provided in a maimer 
which minimizes memory use and maximizes processor performance. 
Consequently, it has been determined that new operating system features must be 
developed which provide media-centric high performance features while 
minimizing memory requiremeius. 

One conventional operating system design paradigm which iias been 
determined to generally consume a large amount of memory is the partitio ning 
of thread coordination mechanisms — such as semaphores, timers, exceptions, 
messages, and so forth — into separate subsystems in the operating system. Each 
such subsystem conventionally includes different application programming 
interface (API) conventions, different data structures, and di^erent memory areas 
used by the kernel to keep track of and to check on them. 
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Another conventional operating system design paradigm which has been 
determined to cause operating system inefficiency in a real-time operating system 
is the manner in wtiich events are transferred to tiireads executing in the system. 
Conventional approaches for delivering an event to a thread involve scheduling 
the thread and providing the event to the thread, even though the event may not 
be of interest to the thread (i.e. , after receiving the event, the thread immediately 
determines that it is not of interest and discards it). Such a scheme wastes 
processing time performing a context switch, and also wastes memory space. 

As one example, if a user presses a key on an HCT keypad, a 
conventional kernel would transfer that event to a thread which handles the event, 
even though the event may be of no interest unless a cursor on the television 
screen is within a certain window. This results in inefficiency, since executing 
the thread involves a context switch, followed by the thread quickly determining 
that the event is of no interest because of the cursor location on the screen. 
Many other examples of such ii^fHciency stem from the fact that threads in a 
system cannot "prequalify** events which they are to receive from the ken^l. 

In summary, conventional operating systems for use in HCT applications 
suffer from performance and memory disadvantages which hinder their utility 
when used for newer, high performance graphics-intensive sqjpiications. 
Accordingly, there is a need to provide operating system features which can 
reduce memory requirements and simultaneously increase the overall performance 
of applications executing in conjunction with the operating system. 



wo 97/24671 



PCT/US96/20126 



SUMMARY OF THE INVENTION 

The present mvention solves the aforementioned problems by providing 
an efficient real-time kernel having features tailored to the needs of HCT 
applications. Whereas conventional kernels typically provide separate event 
subsystemis, semaphore subsystems and queue subsystems, one aspect of the 
present invention contemplates replacing such subsystems with a single, 
integrated event subsystem which provides the functionality of semaphores and 
other synchronization mechanisms through events on event queues. Instead of 
using different data structures to provide these different services, a single event 
data structure can be used. This single data structure can be optimized to speed 
up the kemeL Because the kernel needs to be aware of only of two states for 
each thread (executing the thread, or waiting for an eveiu to deliver to the 
thread), kernel efficiency can be increased. In contrast, conventional kernels 
typically require that the kernel distinguish between various other states, such as 
waiting for a semaphore, an event, message stream, or an I/O operation, thus 
resulting in increased complexity and increasing memory requirements in the 
kernel. 

Another aspect of the present invention contemplates providing means for 
each thread to "register** with the kernel to indicate what kind of events (or 
classes of events) the thread would like to receive. Each thread can also specify 
a "filter** procedure which, when an event is posted to the system (but before it 
is delivered to the thread), decides whether the posted event is appropriate for 
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that context or not. This filter may be an interrupt service routine wiiich nins 
at interrupt time instead of invoicing the destination thread, which would require 
a context switch. 

As used herein, the term "home communication terminal" (HCT) will be 
5 understood to refer to terminals that can be used in tel^hone networks, cable TV 

or other audiovisual programming networks, satellite networks, or combinations 
of these. 

Various other objects and advantages of the present invention will become 

apparent through the following detailed description, figures, and the appended 
10 claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows one possible configuration for a home communication 

terminal (HCT) on which an operating system employing the pritK:ipIes of the 

present invention can be installed. 
15 FIG. 2 shows schematically how a kernel event haiKiler 204 constracted 

in accordance wiA the present invention can efficiently handle and fdter 

incomiiig events. 

FIG. 3 shows steps which may be executed by a kernel event handler to 
efficiently handle events in an HCT. 
20 FIG. 4 shows an example of different threads having registered interest 

in different types of events. 
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FIG. 5 shows one possible format for an event object in a system 
employing the principles of the present invention. 

FIG. 6 shows how two threads can implement a semaphore by using a 
queue wherein a kernel implements a NextEvent function. 
nKTAf]r,f!T > DESCRIPTION OF THE PREFERRED EMBODIMENTS 

FIG. 1 shows a block diagram of a home communication te rminal (HCT) 
in which various principles of the present invention may be practiced. The HCT 
may include a CPU card 100, graphics card 101, decoder card 102, display panel 
and key pad 103, main processing board 104, front end 105, tuning section 106, 
and audio section 107. It is contemplated that the inventive principles may be 
practiced using any suitable CPU 100a such as a PowerPC or Motorola 68000 
series, with suitable EPROM 100c and RAM 100b. It is also contemplated that 
application programs executing on CPU 100a can interact with various 
peripherals such as a mouse, game controllers, keypads, network interfaces, and 
the like, as is well known in the art. 

FIG. 2 shows schematically how a kernel event handler employing various 
inventive princq)les can efficiently handle incoming events and prequalify the 
events to certain threads executing in the HCT. Generally speaking, different 
threads in the system may be interested only in certain Qrpes of events, and may 
wish to ignore other types of events. Examples of events include: a keypress on 
a keypad attached to the HCT; a mouse movement indication received from a 
mouse attached to the HCT; a button press on a game controller connected to the 
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HCT; a message received from a headend coupled to the HCT; or a signal 
indicating that a movie has started. Exan4>ics of different threads (which may 
be concurrently executing in a multi-threaded kernel) include a copy of a video 
game operated by a first player; a copy of a video game operated by a second 
player, an on-screen programming guide; a movie player; a channel tuning 
indicator; or a user interface for a customer billing ^plication. In general, one 
application may correspond to a single thread, or a single application may be 
partitioned into multiple threads which may be concurrently executed to optimize 
performance. One of ordinary sidll in the art will recognize how various 
applications may be constructed out of a single or multiple threads in the system. 

A customer billing application may only be interested in events occurring 
from the HCT keypad, and only if the customer has fu^t entered a special code. 
Two video game threads may be interested in all key press events occurring from 
either of two game controllers coupled to the HCT (thus requiring copies of the 
same event to be posted to both threads). An on-screen programming guide 
thread may only be interested in keypress events which occur when the mouse 
cursor is positioned within a certain predetermined area on the screen, and to 
ignore ail other events (including keypress events when the mouse cursor is not 
positioned within the area). Many other examples are of course possible. Each 
thread may thus wish to register interest in a plurality of different types of 
events, and may wish to change the registered interests at a later time. 
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FIG. 2 shows an exemplary configuration including a kernel event handler 
204 which can accomplish the above objectives. As shown in FIG. 2, two 
threads A and B can each register interest with the kernel in two different events 
using a fixnction pk^Registerlnterest (see AppeiKiix 1), a kernel-provided 
progianuning interface. A corresponding function pk_RemoveInterest allows a 
thread to remove an interest in a thread (see Appendix I). In response to 
invocations of pk_RegisterInterest, the kernel constructs an everu interest list 200 
which may comprise a linked list of 'eveni interest" objects 200a, 2(X)b, and 
200c. For example, thread A may register interest in an event corresponding to 
event interest 200b, and thread B may register interest in an event corresponding 
to event interest 2(X)c, each of which are specified by parameters in 
corresponding function calls to pk_RegisterInterest. It will be assumed for the 
exan4>le in FIG. 2 that thread A comprises a video game application which is 
only interested in key press events from game controllers, while thread B 
comprises a billing application which is only interested in button presses from a 
mouse. 

In various embodiments, the kernel manipulates event interest list 2(X) in 
response to calls to pk_RegisterInterest and pk Removelnterest. When kernel 
event handler 204 receives or generates an event, it traverses event interest list 
200 to determine the conditions under which various threads in the system should 
be invoked. In general, by comparing an event descriptor (which describes the 
event) with parameters included in each event interest object, kernel event 
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handier 204 can efficiently determine whether and how to invoke any thread 
wtiich iias expressed interest in an event. 

Each event interest object 200a, 200b, and 200c may comprise a code 
field, a mask field, a filter procedure field, and a queue field in accordance with 
the parameters set forth for pk_RegisterInterest. For example, when thread A 
registers interest in certain game controller events, it specifies code2, niask2, 
filtet2, and queue2 as parameters in function pk_RegisterInterest. 

Reference will be made briefly to Appendix 1 , which includes descriptions 
for a plurality of fuiK:tions which may be used to carry out various principles of 
the invention. For each function in ^pendix 1, a syntax including a list of 
parameter types and examples of use is provided. Referring to function 
pk_RegisterInterest, for example, thread A would invoke this function and supply 
parameter* values for code, mask, filter, and queue (the filter and queue 
parameters are optional) in order to direct the ken^l to prequalify and direct 
events to thread A. 

The pk^Registerlnterest function (see Appendix 1) creates and registers 
an event interest with the kernel. Its code param^er specifies a description of 
the desired event, its mask parameter specifies an event mask which further 
clarifies events of interest, its filter parameter specifies an interrapt service 
routine (ISR) for the kernel to call when the event occurs, and its queue 
parameter specifies a pointer to the queue to which to route events. 
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Each event interest object, such as element 200b in FIG. 2, holds a mask 
and a code specifying a "desirable" event descriptor for an incoming event. The 
mask specifies which fields of the event descriptor are germane to the specified 
interest, and the code specifies the values that those fields must have in order for 
the posted event to trigger the event interest. 

Bits in the mask field can be used to indicate which fields of the event 
descriptor are germane to a particular interest. One possible example is to 
allocate 32 bits to the mask field. Of the 32 bits, 8 bits can be allocated to 
indicate the device type (i*e. , the device type which generated the event), another 
8 bits for the device instance (i.e., the instance of that device type which 
generated the event), another .8 bits for the event type (i.e., what tjrpe of event 
the device generated, such as a key press), and another 8 bits for event data (i.e. , 
a small amount of data which can contain the event information, such as the 
specific key which was pressed). Such an allocation is by way of example only, 
and is not intended to be limiting. 

Corresponding fields may be included in each event descriptor, as 
indicated by event descriptor 201 in FIG. 2, for example. Thus, each event 
descriptor can include an indication of the device type, device instance, event 
type, and event data correspoiKiing to the event. 

To register interest in events from any device type, a thread would set the 
device type parameter to all ones. The following (hex) masks could thus be 
defined: 
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kDt^Any OOFFFFFF any device type (bits 24 to 31) 
kDi^Any FFOOFFFF any device instance (bits 16 to 23) 
kEt Any FFFFOOFF any event type (bits 8 to 15) 
kEd^Any FFFFFFOO any data values (bits 0 to 7) 
For example, to register an interest in all game controller events, an application 
would call: 

pk Registerlnterest (kDt_ControlIer, 

kDi_Any & kEt_Any & kEd^Any, NULL, my_Q) 
where kDt_Controller is a code correspomling to the game controller, and the 
event mask multiplies to the value FFOOOOOO (no filter procedure was specified). 
As can be seen, the mask FFOOOOOO would cause all the device type bits 
to be set, forcing a comparison of device type with that specified in the code 
(i.e.. Controller type), but leaving zero ("not caring about") the device instance 
(the next 8 bits), event type (the following 8 bits), or the event data (the last 8 
bits). It will be appreciated that an event descriptor could be created with subsets 
of the above fields, or with entirely different fields which qualify a particular 
type of event. 

Returning to the example in FIG. 2, suppose that thread A wishes to 
register interest in all game controller key press events which occur when the 
cursor is within a predetermined screen area, and to ignore all other types of 
events. Thread A creates an event interest 200b by specifying mask2 which 
specifies "device type" as a qualifier, leaves the device instance open, specifies 
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"event type" as a qualifier, and leaves the "event data" open. Additionally, 
thread A specifies code2 which identifies "game controller" as the device type 
and "key press" as the desired event type. Finally, thread A specifies a filter 
procedure 203 which is to be executed to further qualify the event, and a queue 
5 onto which the event will be placed (queue2). For the example shown in FIG. 

2, filter procedure 203 checks the cursor location to ensure that it is within a 
qualified area before passing on the event. It is assumed that filter procedure 
203 executes in kernel mode, thus avoiding a context switch. In other words, 
thread A will not be scheduled by the kernel unless the event meets all of thread 

10 A's qualifications. 

When an event from game controller 205 is generated, an event descriptor 
201 is created which corresponds to the particulars of the event. A device 
driver, which detects a hardware change, can post such an event using 
pk PostEvent (see Appendix 1), For the example in FIG. 2, the "A" button on 

15 game controller 205 has been pressed, and event descriptor 201 thus indicates the 

device type as game controller ("1"), the device instance as "1", the event type 
as "key", and the event data as "A", corresponding to the "A" button. Kernel 
event handler 204 receives the incoming event (from pk_PostEvcnt), and 
traverses event interest list 200 to match the incoming event to events of interest. 

20 In a preferred embodiment, the event matching step may be performed 

very efficiently by multiplying the mask of each event interest object with the 
incoming event descriptor, then comparing the result with the code of the event 
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interest object. If there is a match, then the event has been pre-qualified. In 
FIG. 2, for example, kernel event handler 204 first examines event interest 200a 
by multiplying event descriptor 201 with maskl and comparing the result to 
codel, and quickly determines that there is no match. This "AND" then 
"COMPARE" operation can be done very efficiently on a CPU (typically, only 
two assembly language instructions are needed), thus adding to the performance 
increase which results from using the principles of the invention. 

After determining that event descriptor 201 does not match event interest 
object 200a, kernel event handler 204 next examines event interest object 200b 
and multiples mask2 by event descriptor 201, then compares the result with 
code2. For the example in FIG. 2, assume that the result is a successful match. 
However, because thread A specified a filter procedure 203, kernel event handler 
204 does not pass the event to thread A but instead executes filter procedure 203, 
which checks the cursor location to see if it is in a valid area. If it is, kernel 
event handler 204 delivers the event to queue2 (also specified in event interest 
object 200b), and thread A can extract the event from queue2 using 
pk_NextEvcnt (see ^^ypendix 1). 

It should be noted that had the event not successfully passed through filter 
procedure 203, thread A would not have been scheduled, thus avoiding a context 
switch and increasing the efficiency of the ken^L In other words, in a preferred 
embodiment, filter routine 203 is executed while the kernel is executing, and 
need not schedule thread A. If only 20% of events are actually of interest to a 
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particular thread, then it is much faster to make the "interest" determination in 
kernel code than in thread code, which requires context switches. 

Continuing with the example in FIG. 2, suppose that thread B has 
registered interest in any mouse movement from mouse 206. It would have set 
up event interest object 200c by way of pk_RegisterInierest, specifying device 
type as a qualifier, but leaving the other mask fields open. For device type in 
code3, thread B would have specified "mouse". When a user presses a mouse 
button* event descriptor 202 would be generated, indicating device type as mouse 
("2"), device instance "1", event type as "key", and event data as "mouse press". 
Kernel event handler 204 would traverse event interest list 200, preferably 
multiplying each mask with the event descriptor and comparing the result with 
the code. When it reached event interest object 200c, it would find a match, and 
immediately place the event on queueS, which was specified by thread B as the 
desired queue (no filter procedure was specified). 

FIG. 3 shows steps which may be executed by kernel event handler 204 
to handle incoming events in the system. It is assumed that an event interest list 
has already been created through the use of pk Registerlnterest calls made by 
threads in the system. Beginning in step 301, the next event interest object from 
the event interest list is retrieved. In step 302, the mask from the event interest 
object is multiplied with the event descriptor corresponding to the event. In step 

303, the result is compared with the code from the event interest object. In step 

304, if there is no match, processing resumes at step 301 with the next event 
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interest object. 

If, in step 304, there is a match, then in step 305 a check is made to 
detemiine whether a filter was specified for the event interest object. If so. then 
in step 306 the specified filter is called, preferably directly by the kernel and 
without a context switch. If the event passes the filter in step 307, processing 
advances to step 308; otherwise, processing resumes at step 301 with the next 
event interest object. In step 308, if a queue was specified with the event 
interest, the event is placed on the specified queue in step 309; otherwise, 
processing resumes at step 301 until the end of the event interest list is reached. 

Note that if no queue was specified, the event can be discarded. Such a 
situation may be desirable, for exan^le, where all of the processing is done in 
the filter itself. For example, if the only thing to be done is to update a memory 
area or other t3rpe of short-lived operation, then it may be more efficient to do 
this in the filter itself (in the kernel), and no queue need be provided (i.e., no 
thread to wake up). 

Additionally* filters can be reusable. For example, one filter might have 
a function of determining whether a cursor is in a particular location on the 
screen; different direads could specify aiKl use this same filter. If, for example, 
three different applications are executing in the HCT, each having a separate 
window on a television screen, and the user moves a mouse over the screen, a 
single filter can be devised which determines whether the cursor is over a 
window boundary for the specified thread. 
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Furthermore, when both a fUter ami a queue are specified, the filter can 
modify the event itself. For example, a filter could change the time of the event 
before putting it on a queue. This could be used, for example, by a "replay" 
filter which changes the time stamp on an event to the current time (e.g., 
translate to current time). Another example involves checking a signature on an 
event before waking up a thread. 

FIG. 4 shows another example which applies the principles of the present 
invention. Suppose a video game to be executed on an HCT provides two 
characters who fight one other, with two users each interacting with a separate 
game controller 401 aiKi 402. The video game may comprise a main video game 
thread 403 which controls overall scoring and game operation, and two player 
threads 404 and 405. In the example of FIG. 4, for example, player 1 thread 
404 controls the actions of a first character on the video screen, while player 2 
thread 405 controls the actions of a second character on the video screen. Thus, 
thread 404 must manipulate the first video character based on actions taken by 
player 1, and thread 405 must manipulate the second video character based on 
actions taken by player 2. Consequently, player 1 thread 404 registers interest 
in all events from game controller ifl (by specifying the appropriate code, mask, 
filter and queue parameters), and player 2 thread 405 registers interest in all 
events from game controller M2. 
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In the design shown in FIG. 4, suppose that player 1 thread 404 wants to 
know when player 2 has pressed a "pause" key on game controller #2, and that 
player 2 thread 405 wants to know when player 1 has pressed a "pause" key on 
game controller #1 (in other words, either player, including the one operating the 
opposite controller, can pause the game). In order to accomplish this, player 1 
thread 404 can selectively register interest only in "pause" events from game 
controller #2, and player 2 thread 405 can selectively register interest only in 
"pause" events from game controller ff\. This avoids having the operating 
system send all events from the opposing game controller to the thread, thus 
greatly increasing efficiency. If each queue (and each corresponding thread) in 
FIG. 4 were provided with a copy of every event generated by each game 
controller, much time would be wasted in processing undesirable events, wasting 
CPU time and memory. By allowing each thread to separately register interest 
only in certain types of events and causing the kernel to only send those types of 
events to each thread, significant performance increases can be achieved. 

Similarly, siq>pose that main video game thread 403 is interested in 
receiving "game events" from each player thread, and registers accordingly. 
Each player thread receives events from main video game thread 403, such as a 
command to cause the character to die because of too many blows by the other 
player. The aforementioned registered interests are indicated by arrows in FIG. 
4, annotated with the type of events registered. 
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Additionally, suppose that instant replay thread 406 provides a capability 
to review all previous actions over a time window. Therefore, it registers 
interest in all events generated by either game controller, and thus gets its own 
copy of each event generated by the game controllers. This avoids individual 
threads from having to send "copies" of events between themselves. 

As yet another example, an on-line TV guide may cause tuning tables to 
be downloaded at unknown times. When a new tuning table is downloaded, this 
could constitute an event. Typically, more than one thread in the HCT may need 
a copy of this tuning table. Thus, there becomes a problem of determining when 
to free up memory used to store the tuning table. This can be accomplished by 
creating a filter which creates a private copy of the tuning table for each thread 
that registers an interest in the tuning table event. Thus, when all threads are 
done using their copies, they will destroy their copy, avoiding the problem of 
determining when the memory area(s) can be freed. 

Note that a single event can trigger more than one filter, and can also 
trigger more than one thread. For exan4)le, one thread can be an event recorder 
(debugger); it would want to obtain a copy of every event in the system. To 
accomplish this, the thread would create a mask which clears all the bits, 
indicating interest in any event. 

The following describes in more detail how thread synchronization 
functions, such as semaphores, timers, media events, exceptions, messages, and 
so forth, can be replaced with event objects and integrated onto an event queue. 
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to mmimize memory requirements and applications development in accordance 
with another aspect of the invention. 

It is contemplated that the kernel deals with time in a very accurate sense. 
A clock generates time ticlcs at a very high rate of speed (e.g., 25 MHz), and 
this clock can be used for timing. In accordance with various aspects of the 
invention, every event in the system can include a time stamp (comprising, e.g., 
64 bits), comprising a '^snapshot" of the system clock. When a event is posted 
or delivered, a future time can be inserted into the event object (instead of the 
current time). Rather than immediately delivering the event to a destination 
thread, the kernel can hold onto the event and not post it until the designated 
time arrives. Therefore, every event has the capability of being an alarm. For 
example, every keypress generates an event at a particular time. 

Instead of writing an alarm procedure which detects that a certain time has 
arrived (to schedule an event), a future time can be inserted into an event object, 
such that when the event is posted, it will not actually be delivered until the 
future time in the event object. This avoids the need for kernel code to 
implement alanns, including the attendant data structures, storage areas, and 
status checks indicating which of several states a thread is in (e.g., ** waiting for 
alarm"). 

FIG. S shows one possible configuration for an event object 501 in a 
kernel, including a pointer to the next event object, a code (corresponding to an 
event descriptor), time, X, Y, Z fields, and a "where" pointer. In various 



wo 97/24671 



PCT/US96/20126 



-20- 

embodiments, event object 501 may comprise 28 bytes including both "public" 
portions accessible by threads and "private" portions hidden from threads. 

Events may be strung together into a list in an "intrusive" form (i.e., the 
objects in the list have in their data structure the fields strung together), as 
compared to an "extrusive" form in which the list component is built separately. 
The "where" field may comprise a queue pointer which is used for 
scheduled_delivery: deliver event to queue at a future time. A thread may set 
the code field (device type, instance, etc.) using pk DeliverEvent where an event 
is created by a thread; alternatively, a device driver may set the code field using 
pk PostEvent as described previously. The X, Y, Z fields comprise "payload"; 
any data (including pointers to data structures) can be included therein. 

As one example, an event structure can be used to set up an alarm. A 
game might have a 3 minute roimd. At end of the round, a bell will ring. A 
thread can set an alarm by calling pk_ScheduledDelivery (see Appendix 1) and 
set the time to 3 minutes from now, and specify the event code, X, Y, Z, and 
the thread's own queue as the "where" pointer. The thread can then use 
pk_NextEveni to get the next event off its queue. Even though different API 
calls are used, a single small data structure can be used, removing the need for 
a separate alarm system and eliminating the need for the kernel to provide special 
functions for alarms. Note that a thread can "pre-timestamp" the object, then the 
kernel can reuse that same space when the actual time is stamped. 
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Consolidating alarm functions into an event delivery function thus saves 
memory, processing time, and programmer effort. When a thread is "sleeping", 
the kernel need not determine whether the thread is waiting for a semaphore, or 
for an alarm, or any other type of synchronization event. This results in faster 
thread switches. Whenever a thread is sleeping, the operating system is always 
watting for an event on its queue. This also makes the kernel smaller. In 
contrast, conventional kernels need to execute instructions to determine whether 
a thread is waiting for an alarm, semaphore, queue wait, message wait, etc. 

A second example of consolidation involves semaphores (FIG. 6). 
Assume that two threads 602 and 603 ne^ to use a single printer. A 
conventional approach is to provide a semaphore to which both threads are 
responsive (i.e., they are in a "semaphore wait" state, and the kernel puts a 
thread on a "semaphore wait" queue with a semaphore wait data structure). 

In contrast to conventional methods, the present invention contemplates 
using an event object. To implement a semaphore using event queues, a queue 
604 is created (typically by printer driver 601) and a single event 604a is placed 
on the qume. The first thread 602 which needs the resource (such as a printer) 
makes a call to pk_NextEvent (see Appendix 1), specifying the printer semaphore 
queue 604. This function causes a wait in the thread if there is no event on the 
queue, but otherwise extracts the event if there is one on the queue. Thus, 
assuming the object is still on the queue, the kernel 605 removes it from queue 
604 and delivers it to thread 602. If another thread 603 attempts to use the 
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resource (by calling pk:_NextEvent), it will cause the thread to wait until the 
event 604a is returned to queue 604 by first thread 602. When first thread 602 
is finished using the resource, it calls pk_RetumEvent (see Appendix 1) which 
returns the event to queue 604, allowing second thread 603 to finally execute its 
pk_NextEvent function. 

Thus, in a preferred embodiment, kernel 605 does not place second thread 
603 in a "waiting for semaphore** or **waiting for alarm** or any other type of 
mode; instead, the common event paradigm is used. This increases the efficiency 
of the kernel because the kernel need not maintain separate queues for all types 
of different activities, and when examining a thread's status, the kernel already 
knows that the thread can be in only one state. Furthermore, the same common 
event object can be used to implement semaphores in the system; no special 
semaphore data object needs to be defined. 

The above example can be extended to handle multiple resources. For 
example, in FIG. 6, if there is a second printer 606 (but potentially more than 
two threads which would need to use the two printers), then each printer could 
post an event onto queue 604; the first two threads which called pk_NextEvent 
would obtain use of the printers, and the third caller would be put in a waiting- 
for-event state by the kernel. This has a further advantage in that no pre-set limit 
on the number of semaphores needs to be specified; the queue can grow as long 
as needed. An event can thus be used for anything; the kernel need not even be 
cognizant of a ** semaphore" synchronization mechanism. 
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To eliminate redundancy and simplify the event system, all of the 
following types of coordination mechanisms can be classified as events and 
implemented using functions such as those shown in Appendix 1: 

— diread synchronization, including semaphores, messages, and queue 
5 messages, all of vddch are passed between threads as synchronization objects. 

— demand scheduling* which signals that a demand was made for the 
upgrade of a thread's priority. 

— timer events and delayed actions (an event can be posted irmnediately 
or at a specified fumre time) 

10 — inter-thread exception handling (an event occurs whenever a thread 

raises an exception) 

— user interface actions, including pressing a button on a remote or game 
controller, changing the volume, moving a pointer device, etc. 

— media events, including starting the playback of audio, reaching the end 
15 of a move, inserting media into or ejecting media from a device, etc. 

— application-specific events (user-defined events) 
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It is s^parent that many modifications and variations of the present 
invention are possible » and references to specific values are by example only. 
For example, although references herein are made to "threads", such a term 
should be understood to also include processes, tasks, or other entities which can 
5 be scheduled by an operating system. As another example, although application 

programming interfaces are described for performing various functions such as 
registering interest in an event, equivalent mechanisms are of course possible to 
implement the same futK:tion. Moreover, specific function names are by way of 
example only. It is, therefore, to be uiuierstood that within the scope of the 
10 appended claims the invention may be practiced otherwise than as specifically 

described. 
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pk_DeleteQueue 

Deletes an event queue. 
Syntax 

-void pk.D«l«CttQMaa<qu«a« *q>j 

Parameters 

Apoxnter to the queue to delete. 

Rotums 
None 
Conwnonta 

liys iunctbm mt otily dclcin the qjcdfied queue, but tees aU the 
I in the qtaeue as welL 



None 



No 
SMAlao 

pl(_nusliQuMM, pUJttmQumm 
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pk_DeliverEvent 

Places an event directly tnto a queue without piocosing the event 
inteiestlist 

Syntax 

▼old pJc^0^1v«r»rea«(qa«u« ul33 coAm, 133 133 y, 
133 S>| 

PBfBniet0fs 



A painter to the qume to which to deliver the 
evcnL 

^oodEc The event type code* 

-♦X An optional event data field, 

-►y An optional event data fidd* 

An optional event data field. 



Returns 
None 




kPtv.MefmcyPufl&T 
{ 

uOS dCu i lnn ir w n l - 0x29000000; 

do 

{ 

- f/ ANemose oOTwoen fmeonp^ ana «eeMraip 
pkJH»»prat (1000 • 2S000); /rStMptBromMeond 
// Broadent art mehidno aonM aifelbwy dan 
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pk_PQStEvent (dtCustomEvont. OacS. 0x29. 0x65): 
pK. S Ie»pFof (1000 • 25000); // Sleep tor one second 
// Poet an event to e specified queue 

p< .Dei w C wBn t (rnyOusue. dtCus iomE we nt 0k12, Ok14. 0x92); 
}wtiae<1): 

} 

SmAIbo 
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pk.EndCatch 



Marks the end of a try-and-oitch block series. 
Syntax 

CofTifnsnts 

TkimiMMmmatK 

ffm exception has not been caught when program 



«xoq)tton » thiowii to an outer try block. The outer 

try bloc k art bdongte«n«pplicmtioB,«de»k«; or tfaeopcnfeg 
sysiaui itaalL 



TW« i« « v«y «apto exMipl. of m «aptian hmdtat The try bk>ek 
«imwnd. th« Pli»MI«l«ilmrtound routine; iwi • 
UeckcMchMaUi • 



MM PliyHighChfcnaSound (void) 
{ 



( 

//CfMM an «u«o pi^fw ttMt cMMM (woureM up 

/'oompMton of playtng itw aowML 

P<«ywPJr . ap_NM)fMMAIFF ((ui8 nHi^.CMm. 

HVuCMn«.^iaa. TRUE): 
// 8M pi^tne tw Mund 
l » _p<i y ( iJ i «i w P>), 

) 

/f CMeh ai autfe mpltom hML 
P<.CMah (liPi(_E]tDapaenM|> 
{ 

^ PrtntfCAudtoairorewi^ktPI^^HVOiimaSoundWi-): 
p((.EndCMh 
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See Also 

pk.AlsoCatch^ plc.C«teh, pK.C«tchClranup 
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pk.FlushQueue 

Flushes an event queue of all even^ 
Syntax 

▼old pJiL.riuabOa«tt« (queue i 
PVBITMtOfS 

A pointer to the queue to flush. 

Returns 
None 
Oomiiwiilj 

This funtlm 6m aU the evanis in tlw ipwafiwl queue: 

Ne 



None 
SmAIso 
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pk.FreeEvent 

Frees an cvcnL 
Syntax 

void pk_FrM«v«ac ( v^rMt 

-^t A pointer to th* event to free. 

Returns 
Nam 
CocnTMnte 

Becastae multiple thxeedi mi^ be mtoestcd in ciqr om ev«^ 
kemei czeetes a new instance of every event that it nnitcs. To 
prevent memory leaks, we recommend explicitly dispoeix^ of 
piooesaed events using pkJ T r mfL ^mnL 

None 
rumple 

This exan^le waits for an event to be received, and ttei frees the 
event wticn the application is dcm wiUtt it 

const TVneVUue kForAMBimnyHy . [QxFFFffFFf. OfcFFFFJ=FFF); 

ev«« 'anEvent; // Where gmepad and eyetameMnis 

//wflbepoeied 

ul32 m0 m tDm km^ //The devloe M posted ttw emtf 
B isianela, /roats posted in ttie event 

anEwsnt • piL.NsBdEwam (gAppCXieue. kFicy^U^ 
evanCata • anemH-Mda 4 h£d.MaelQ 
mmJiOm km m an C va ni j oode 4 (uOg tt^Mask; 

SMAIao 

Mane 
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pk^Galloc 

Allocates memory from the genera] heap. 
Syntax 

Pmmnmimn 

"^"^^ mbytes, of the block to allocate. 

Returns 

Apointetptt».lloatedblixk.«IWLLifthe»i.in«^^ 
memory available mw 

Pofnfn#nte 




Mom 
Exampl* 

Nom 
S—Mao 
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pk.Gfree 



Frees a memory block in the general heap. 
Syntax 

▼old pJt.0CrM(^id *p)i 
Parametara 

^ p A pointer to the mcmoty block to free 

RMjma 

NOM 

CofTwnaftfeB 



Ni 
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pk_Launch 

Creates a new thread. 
Syntax 



Boolaaa pk^x^auach ( void (•codaXiroid « 

ai^aa.t m^K^mtzm, ^Id •data* ui^a priority) « 

Pntwnwtmn 



A pointer to the code to be executed by the 
thread* 



-^d Apcsntartoaparazneter forcode. 

-^s<Ow 1hesisa,inbyte9,oftte stack to allocate lor this 



thread. 

A pontter to a pnvata data J 

-^fmmtfy Tlia thread pnocity. The lower 5 bits represents the 

pnniQr^ whkfa can range from 0 to 31* 

ftotums 

TRUE if thread was launched sucoessfuUy, and miSE if the 
specified prkaity is already in use by another threid* 

Convnenia 



No functian esdsti for deleting the thread because the thread is 
eulmaticaay deleted when the hsMion specified by csd^ 



nrw^iMenMSfyrvacffr 



'^tiocity). 

««W LaunchOnNM (Mid) 
( 

uiS prtofttyalfl; 

whi» (p»0,Bunc#i (luncbonPtr. 0x4000. •PTV_>Kopac«tton'. prioiHy)) 
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) 

See Aldo 

pIc.LAunctiNcttfy^ pt^LaunchThreed 
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pk.LaiinchNotify 

Creates a wrw thread. When the thread is deleted, a M 
event is sent to the specified queue. 

Syntax 

Immn pK.X-auachMoel£y <irol4 CeodeX^ld •d), 
■^••-^ at^^ala*. ^Id *daM, uija priority, 
noztty} 9 

A potnler to titw code to be executed by the Mw 
thmd. 

A pointer to a panmeter for code. 

-^stk,^ 'ni«ai»,inbyte^oftheatKictoaaocateforWa 
thmd. 

-♦dots A pointer to a private data azea. 

-►pnorfty 'H'^ priority. The lower 5 Wta represents the 

pzteity; wMch can range tern 0 to 31« 

"^''^^ Optionally, a pointer to a qumc to receive a 

tcECpAcThrMdExit event on exit 



Parafnetara 

oodr 



TlUE if die thzaad was launched sacoesafitny, and if the 

•p a rified priority i» already in uae by another thread. 



No ftanction exists for daMng tt« thread because tha 
ntonaticany dalated wfhen the hoKtibn specified by a]d^ 



I^.Memoryfnji&r 
hPlv.Param£fr 



Mom 
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pk_LaimchThread 



Creates a iww thread md xetums the thread identifiex: When the 
thread is deleted, a notification event is sent to the specified queue 
Syntax 

tti3a pJc^J^a qachT fcraad i Toid (•eodeX^ld •d), 

elsa.c mzk^mtsm, ▼old •daM. uXSa app_priorlty, 

Parari iet0i s 

-^cadle A pointer to the coda to be executed by tte new 

thnad. 

A potntK to a parameter for oNle. 
-#stft;..^iar Th»sii«,inbjrtei,af the stack to allocate for the 



-♦data A pointer to a private data I 

-^itppjfriority The application cxecutian priority. T)w lower 3 bits 
represents the pricmty, which can rartge from 1 
(Mghnt) to 7 (lowest). 

^ not^ An optional painter specifying a queue to reoezve 

the l£LWn«MdExit event when the thread has 
nsn to copipietiort. 

Returns 

The tfarMdidcntifleR a number tern 1 ton. 



No fuiictian odats for dektiztg the thread because the thread is 
r deleted when the haiction qpedfied by oodr 



None 
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pk.Lock 

Locks the kjemtL 
Syntax 

▼old pK-lieekOi 
PararfHitorft 

NOM 

R6tuni8 
None 

This functian dissbics xntemipts, thereby pxevcnlxx^ contact 

F fl 'i f?t ptfn fw 

None 
Exsmpto 

NOIM 

SmAIso 
pl^UnlMlc 
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pk_MakeEvent 

Creates an event but does not deliver it 
Syntax 

• Pk,jtak*«^t(ul3a coda, 13a 13a y, 13a 

PaiHrn«t»fs 

code event type ood«. 

^ ' An optional event data fi^M 

An optional «vcnt data field. 
An optional event data field. 

B«tuma 

A pointer to tha neW «v«nt 
Conviionls 
Ncm 



fc^.MamoryftilErr 
Nora 
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pk_NewQueue 

Creates « new event queue. 
Syntax 

None 



A pomtw to the new queues or NULL if time w« ini^^ 
ncmary from which to allocate a new queue, 
f^nmynanta 



kPty_Mamory ru lErr 

Nam 
SMAIao 
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pk_NextEvent 

Gets the next event from the specified queue. 
Syntax 

ParunetMi 

■'^•quwM^wm which to i«ti»v« the next emu. 
-»(iniantf T** «*«*«t which to wtura if «n event has •tiU not 

ben delivered to the queue spcdfied by f. 

An applieMion em abo ^Mdfjr kPiv.Fara«w to 
wait an indefinite period of time end xctum only 
when an event is deUverad to the queue. 

Ratuma 

A pointB to the nest event; or NULL if • tineont occumd 
(signalling that the queue is atOl CB^). 

ConiRMniB 

NOM 




This allele «vaiti far an event 

teeCnei* • pt(_NeKiE«ent (myOueue. fcPtv. F oreww); 

SMAIao 
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pk.NextEventCritical 

Gets tKe next event £rom the specified qxieue. and upgrades the 
calling thtead's condition to cziticai at some point 

Syntax 

PSfBIIMllMS 

f The queue tern which to retrieve the rmxt event 

^timmU TlMamouxtf of txiiw to%vaitf6ranevcntbcfm 

retuxxdrtg* 

dmdJme When to upgrade the calling thread's condition to 

rritinl 

Recurm 

A pointer to the next event or NULL if a timeout oocuned 
(signalling that the cjueue is ttill empty). 

Cofivn^nto 



Nam 
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pk.NextEventlmmediate 



Syntax 



-►f "^^^^"^ to retii^r. the n«xtev«t 

A polntor to *• not event or NULLif ih, i, 
CofffVfwtti 

No 



SmAIm 
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pk.PeekEvent 

Ketiirm a pointer to the specified evem in a quelle. 
SyTTtax 



ParametM 

^P««*« to the queue in which the event resides. 

"Hie event number to which to retum a pointer (1 
for the tet 2 Ibr the aeoocid, and ao on). 

Rettms 



A paimer to the epedfied event or Wli II the evem does not exist 
Convnenta 

; the queue. VVe iceomnumd that you Jock thieads as 



Nan* 
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pk_PostEvent 

Posts an event 
Syntax 

▼old plc.Fo«t:»^«n6(ul33 co4«, 133 x« 132 r« 133 s)i 

^codg The «v«r type oodtt. 

X An optional event data field. 

-»y An optional event data fidd. 

^ z An optional event data fidd. 
Roturm 

NOM. 

OommenlB 

The event type {ki conjunction with the zxuak) is diecked againat 
eech event intmst in the order in which tha event tnterasts iveie 
legistived. When a mafich is ftnmd, the event intirest is tzigg^^ 

If a fiUar was ^edfied, the filter pnxxduxe is called and dw letuzn 
code detanntnes whether a cc^ of the event is sent to the queue. If 
no filftK was apedfied* the event is deiiveted dizecdy to the queue. 

Pbsting an event may trigger multi^ event intnesti and fesult in 
multiple copies of the event being ddivered lo multiple queuas. 

void EventBaelsr (voU *dafea) 
( 

uia2 dICu atei i C wen t • 0x29000000; 



//Eveiyfie 
//Allamafte 




poet en ^ent 

_ -* - ^ — ' — * 

n posanp ano iseeverv^ 
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pk,al— pror (1000 • 25000); //Ste«p tor on« saoond 

// BrtwdcMt an «v«rtt inducfing some «ftctmry data 
pK.Poat£vwrt (dtCustomEvanl, 0x8. 0x29. 0x65); 

pk^SlaapFbr (1000 • 25000); // Stoap for one saoond 

// Poat an Mm to a apaafiad quaua 

pleDaivarevart (myOuaua. dtCuatomEvant 0x12. 0x14, 0x92); 
)whia(1>: 

) 

SaaAlao 

plL.OalNar€Mnt pl^.9ohadulaCvant 
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pk.Registerlnterest 



Registers an interest in a particular class of «vaits. 
Syntax 

Prnmrmlmm 

-^cede T*»«v«t type in which you are intwatecL 

An event mask which furtte darifies evotts of 



-^fiUer The interrupt senri^ routine (ISR) to be called 

when the event is 1 



This piooeduie takes a pointer to tt« event as an 
ugument and xetums a boolean value. 

A pointer to the queue that xcceivcs events. 



A pointer to the event interest 
Cofivfienfa 



An event interest ^eofies a type and mask which detcnnine the 
I of events to watch fac 



You can supply a filter prooedure that is caDed immediately what 

the event is posted and that operates in tttt contnt of tl» event 
cteaftor (which may be an lat). 

An event interest may have only e filter or on^ a queuet, or it may 
have botlL 



// 



(WUConlroler I IdDLPteyen , l£U^ny 4 IdSd^^ 
myOueue); 
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pk.Ragistaflntafeat (kOt_Rwnota I WDi.Ptaywi. kEl Any 4 kEd Any o 

plt_R«g»t«rtnterB« (kOt_Conaoi« I KDl.Ptey^. KEt Any & kEd Aml 0 
myOiMiM): - ' 

pleRagiMwtntwwt (M)t_Sy«am I kEt_PkThfMdEx^ kEd.Any, 0. 
myOuMM); 

pK.R«gistw1ntw««t (dtCiMtomEMnt. kSLAnf 4 hEd^ny. 0. myQiMtM); 



See Also 
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pk_RemoveInterest 

Removei an event interest 
Syntax 

wld pk_K f^ V Tn t wet < mi 'lAtMMt)! 

^ attermi A pointer to an event interest 

R6titfn0 
Nam 

COITVTWniB 

If tte vahie of mimst is not v«lid^ it k assuined to have been ai^^ 




NOM 

SMAIao 

pll_(laglMn«Mwt 
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pk.Rethrow 



Passes the exception raised by pl^_Throw from 
an outer try block for continued processing. 

Syntax 

PflLfwnotttfS 
Nam 

COIIUIIOf lis 

TItts Is « MMTO. pl^Rettifoir is equivalcm 



This inecro can be thought of es en altemAlive retimi mechanism. It 
I contfoK to the outer try block so that the exception can be 
. Contpol does not return to the k)cation wlwR the 



pA^TIu uwlfNutI 
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pk_RetumEvent 

Returns an event to a queue 
Syntax 

Parameters 

Apotntcr toaneventqueue. 
Apoinlertotheevcnttoretuxnp 

Relume 
None 
Convnenia 

Uae ptciMumfivant ptixnarily for impksianting teni^hotca. 
Certain evenls» euch aa tcmaphoie evcnti, ham liini^ 
can be nmtad to, at inoat om queue. Whan letxieving such e 
far pn xasaUi ^ we l e c o mi nand using picWetumE¥ent%vhichiout^ 
the actual event rather than a copy of the event 

Nona 
Example 

Nona 
SeeAleo 

pleJiBlCventtmmedMa 
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pk.RetumlnTry 

Executes « C f«um caU frtmi within a try block 
block off the exception handling stack. 

Syntax 

pk.B«euxnZa9ry<Me) / 

Pammetttrs 

— > rri Thm return value. 

Oonvnenta 
ThiMismt 



Attcmpti to oae a ttandard ratum can tern within a try blodc wffl 
wult in an irwattd excBptifln atacfc and aiqr 

win cauaeoorttrnl to be paaacd incorrectly to the catch blocka 
1 with the try block. 



None 
SMAteo 
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pk_ScheduleDelivery 

Axnnges for the future delivery of an event 
Syntax 

ttiaa code, 13a x« 133 13a s>i 

ParafMt»m 



^ fptov The queue to whkh to deliver the event 

The deixvcry time. 
-»oade The event type code, 

-^x An optional event data field. 

— >y An optional event date field. 

An optional event data field. 

Retume 



None 
CoCTvnenla 
Nam 

iirfv^ivivvfiQTyriaicffr 

Mom 

pi(.OeOvefCven^ pi^PoetCvent piL.8otiadule(lvMit 
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pk.ScheduleEvent 

Posts an event at a future time 
Syntax 



133 y« 


133 ■)# 


PararrMtftrB 






Tha ddivcry time. 


— ► cod* 


The event type ^vwie 




An optionai event data fidd. 




An optkanal event data field. 




An optional event data field. 


Returns 





Notm 
Contfnenti 

If the time haaaliwadypaaaed»^ienplL-8ctiedulaC»ent is called, tte 
evou is delivered immediately. 



ItPlv.MemofyPulKrr 
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pk_SleepFor 

Sleeps (blocks) for a specified number of dock ticks. 
Syntax 

*vold pk.SlMpPor(ttl3a eloeJKleke)/ 
PanuMtM 

-^cIcektkkM The number of dock ticks to block for. 

Nam 
ConvnOTte 

This function implements « timeout with an «ccttnc7 of 4-/- 5 
milliinisuli 

None 
Exampto 

voU C ventfta ef f (void *data) 
{ 

ul32 dlCuslomEvent « (toOMOOOOO; 

do 

{ 

// Every 5 eeeonds poet an SMM 
//Allemaio between 'poetintf' end ^d ei verintf 

pK.8leepFor(100O*2S000>; AT Sleep for one second 

// Broedoaet en inchjctng sorne erMmry dele 
pK-PoelEMnt ( dtCimmC ws nC OkS, 0x29. OM0h 

pleSleepFor(1000 * 2500q>; i/Slespforcmeeoontf 
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// Post m «Mnt to « tp«cffM quoM 

pk.Oefivw€v«nt (myQu«u«. dtCustomEvent 0x12. 0x14. 0x92); 
} white (1); 

) 

Sea Also 
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pk^StackAvail 

Detttinines how much of « thread's alloca^ 
Syntax 

PammctM 

^thnmOD A t^w^i^l^ntifitt: returned by one o^ 

pii;_Launch* hmctionA. 

CofTvnents 
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pk.StackProbe 

Raises an exception if the stack allocated to a thread has been 
exceeded. 

Syntax 
Pwnetsfa 

— f threadSD A thread identifiei; letuixied by one of the 

pK^Launeh* functions. 

Convnenta 

Use thia functian during development to check whether or not a 
thzead'a alkated stack has been exceeded. 

IcPtv.StadeCXartlow 
Exampla 

Nom 
SMAiao 

pICtMnoh, pIcLaunchNetlfy, pIcLmnehThfaad, pte^StaacAvait 
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pk_StackSize 

Detennincs how much stack was allocated for a thread. 
Pacwmlara 

^thrtadlD A diiead identifiei; returned by one of tiw 

pl^taufwH* functiona* 

Coffnmanta 

UiiMitmmimav, 

Mom 
SmAIM 
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pk_TakeEvent 

Takes an event from a qumie. 
Syntax 

Parafnotftfs 

-^f A pointer to the queue from which to take ttv 

event 

-^n Theeventnumberto take(liarthefint 2f6rthe 

second, and so on). 

Rotufns 

A pointer to the event <v NULL if the event docs not exist. 
Convnonts 
Nam 

Mom 
Exampto 

Nom 
SmAIm 
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pk_Throw 

Rai»« an excq^don by pMsing the specified cnor to the system's 
exception handler. 

Syntax 

pJ^tbrovC type) 9 

PeremeterB 

^yp^ The exception type. 

CofTvnenie 
Thimitmi 



I control to the outer try blx>di so that the exception cm be 
Control docs not ntum to the locatian whBR the 



NdM 

pi^Tf II uwtfNuM 



SUBSTITUTE SHEET (RULE 26) 



wo 97/24671 



PCT/US96A20126 



-63. 



pk.ThrowIfNiiU 

Raises 4 kPtv.MemoryFuflEfr ocception to the system's exception 
handlet if the pointer is nulL 
Syntax 

P^TlkMwznt&Xl (void •wroiaew)/ 
ParametMs 

— ♦ myPomUr A null potato: 

r*nfnfnaiiia 
TkiBimm 



TW« m«TO c» be thought of «» an altenMthre 
w yflgmter is NULU it peases 

ex^U^cmbeproceseed-ContmldoesiiotxetiOTi to ti^kxatto 
wfaeer 



plC.ThfMrlfNuM is uscfttl after any cell thet 



{ 

II 



eori M ee tfih am dScf Bei 1 (appCCX 

fcSflr,SaeenMode,LPw ft eeo h ittonKTSC); 



p>eCiieh (tfUJmeudunAD 

( 

// 

} 
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Delimits • block of code in which to 
Syntax 

pit-Try 

Comm«nts 

This function ddindti a block of cod« 
proctagmg functinnaUtv iar th^ «r»pH^ 

«iy block d«emriin» it. prio^^ 



Atry btockMpu«hedoototh««xcepttan -«^ ^ ^ 

to IW. try Woek-. catch loulin.. or to ttut of lati te^^ 
unta«mcutian of this tiy Mode conqytetn. 



TO« !• • vey tfmpl. ««nq,j. of « «OBption hmdltt Tl^ 
«tt«a«l. th. PtarW9l»CI,lm.8ou«d 
block dtctoaUc 



«eU PlqrHlahCMRMSowid (void) 
{ 

ui32| 

P«0»y 
( 



// comptMon of pliyine ttto I 

pta»ort*- IPJWUMAIPF ((uM THi^CI*!** 

Hi9i_CNmo.tin^ TRUE); 
tfStvtpliyinottwi 



pleCMeti (KPluEwipdanAI) 

{ 
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phntf TAudio eiw cuj^ in PlayHighCKnrwSound\n'): 

) 

pK_EndCateh 

) 

SmAIso 
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pk.Unlock 

Unlocks the kernel 
Syntax 

▼oi4 pk.O&Xoek{}# 

PwnotaiB 
None 

OOfTtffMfllB 

This function re-enabks izdem^, thcr^ enabling con^ 



mm 
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CLAIMS 

1 . An operating system kernel for execution on a home communication 
terminal (HCT) on which a plurality of different events can occur and a plurality 
of different threads can be executed, the operating system kernel comprising: 

an event registering function which allows each of the plurality of 
different threads to register interest in one of the plurality of different events by 
specifying parameters which indicate qualifications for the one event of interest; 

a f^a^ structure conq>rising a list of event objects each comprising oitt or 
more parameters specified using the event registering function; and 

an event handler which, responsive to receiving an event descriptor 
corresponding to one of the plurality of different events, traverses the data 
stmcture, compares the event descriptor to one or more of the parameters in each 
of the event objects and, responsive to a determination that the descriptor 
matches the one or more parameters in a particular one of the event objects, 
provides at least part of the event descriptor to a thread having an interest 
registered in the one evenL 

2. The kernel according to claim 1 , wherein each event object comprises 
at least two parami^ers, a first parameter comprising a code field and a second 
parameter comprising a mask field, wherein the mask field indicates which of a 
plurality of fields in the event descriptor are germane, and wherein the code field 
indicates a value that each germane field in the event descriptor must match. 
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3. The kernel according to claim 2, wherein the event handler multiplies 
the mask field with at least part of the event descriptor and compares the result 
with the code fleld in order to perform the comparison. 

4. The kernel according to claim 3, wherein the event handler places the 
at least portion of the event descriptor on a queue designated in Che event object. 

5. The kernel according to claim 1, wherein the one or more parameters 
indicates a device type and an event type to t>e qualified. 

6. The kernel according to claim 1, wherein each of the one or more 
parameters indicates a data value representing a key press from a device coupled 
to the HCT. 

7. The kernel according to claim i, wherein the one or more parameters 
comprises a filter to be executed by the event handler to further qualify the event 
descriptor. 

8. The kernel according to claim 7, wherein the filter is executed in the 
context of the kernel rather than in the context of a thread. 

9. The kernel according to claim 7, wherein the filter checks a position 
of a cursor witii reference to a window in order to further qualify the event. 

10. The temel according to claim 7, wherein die event handler compares 
the event descriptor with the one or more parameters in each of the event objects 
and, responsive to a determination that the descriptor matches the one or more 
parameters in a particular one of the event objects, executes the fdter prior to 
providing the at least part of the event descriptor to the thread having an interest 
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registered in the one event. 

11. The kernel according to claim 1, further comprising an event 
deregistration function which allows each of the plurality of different threads to 
remove a previously registered event interest. 

12. A method of fdtering events in an operating system kernel executing 
on a home communication terminal (HCT) having a plurality of threads. 

comprising the steps of: 

(1) registerii^ interest in one or more events from one of the plurality of 
threads by creating a data structure comprising one or more parameters which 
limit the type of events which arc to be provided to the one thread; 

(2) detecting that an event has occurred in the system and, responsive 
thereto, creating an event descriptor which describes details of the event; 

(3) in the operating system kernel, comparing the event descriptor created 
in step (2) with the one or more parameters in the data stmcmre created in step 
(1) and» responsive to a determination that tte event descriptor matches the 
event, providing at least part of the event descriptor to a thread corresponding 
to the data structure. 

13. Tte method of claim 12. wherein step (1) comprises the step of 
creating a data structure comprising a code field and a mask field, wherein the 
mask field indica^ which portions of the event descriptor are germane to the 
comparison in step (3), and wherein the code field indicates a value that each 
germane portion in the event descriptor must match. 

SUBSTITUTE SHEET (RULE 26) 



wo 97/24671 



PCT/US96/20126 



-70- 

14. The method of claim 12, wherein step (1) comprises the step of using 
panuneters which indicate a device type and an event type to be qualified. 

15. The method of claim 12. wherein step (1) comprises the step of 
specifying a filter to be executed by the kernel to fitrtiier qualify the event 
descriptor, and wherein step (3) comprises the step of executing the specified 
filter prior to providing at least part of the event descriptor to the thread. 

16. The method of claim 15. wherein step (3) comprises the step of 
executing a filter which modifies the at least part of the event descriptor prior to 
providing it to the thread. 

17. A method of implementing on a home communication terminal 
(HCT) a semaphore function using an operating system kernel which lacks 
semaphore functions, comprising the steps of: 

(1) creating a queue for a shared resource using a kernel-supplied queue 
creation function which is accessible to threads executing on the HCT; 

(2) storing an event object on the queue, using a kernel-supplied object 
delivery fimction which is accessible to threads executing on the HCT, to indicate 
the availability of the shared resource; 

(3) from a first thread, executing a kernel-supplied object retrieval 
function which retrieves the event object from the queue, wherein if the event 
object is not on die queue the first thread is suspended by the kernel; 

(4) from a second thread, executing the kernel-supplied object retrieval 
function to attempt retrieval of the event object from the queue, and, upon failure 
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to retrieve the event object from the queue, suspending thereby the second 
thread; and 

(5) from the first thread, executii^ a kernel-supplied object release 
function which returns the event object back to the queue, and thereafter 
S resuming operation of the object retrieval function started in step (4). 

18. The method of claim 17, wherein step (2) comprises the step of 
storing a plurality of event objects on the queue, each corresponding to one of 
a plurality of shared resources. 
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FIG. 3 
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FIG. 4 
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FIG. 6 
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